Skip to content

Make brightness keys work on external displays with a kernel backlight - #687

Closed
wesleygrimes wants to merge 3 commits into
omacom:quattrofrom
wesleygrimes:brightness-connector-backlight
Closed

wesleygrimes wants to merge 3 commits into
omacom:quattrofrom
wesleygrimes:brightness-connector-backlight

Conversation

@wesleygrimes

@wesleygrimes wesleygrimes commented Oct 3, 2026 •

Copy link
Copy Markdown
Collaborator

Problem

With an Apple Studio Display focused, the brightness keys show the OSD but the display doesn't change. The keys go through sudo asdcontrol, and Studio Display firmware 17.0 ignores that brightness command (macOS sees the same thing).

The sudo prompt also holds the brightness lock until it times out. Until then every brightness key press is dropped, including ones for the laptop screen.

Fix

Kernels with aurora-linux#15 (still open) expose the Studio Display's brightness as a regular backlight device (e.g. dcp-DP-3-bl), attached to the display's connector. When the focused external display has a backlight like that, the brightness keys now use it the same way they use the laptop screen: brightnessctl, the usual step sizes, the OSD, and no sudo.

Everything else behaves as before:

  • Displays without one, which means every display on a stock kernel, DDC monitors, and Studio Displays on older kernels, take the same path as today.
  • Laptop screens keep omarchy-hw-display's choice. Some GPU drivers attach a backlight to the internal connector that isn't the one driving the panel (gmux on dual-GPU Macs), so internal connectors aren't checked.

Only a connected connector's backlight is used, so a disconnected connector with the same name on another card can't be picked instead.

The check isn't Apple-specific: any external display whose kernel driver provides a backlight gets the same treatment.

Testing

  • New cases in test/shell.d/brightness-display-test.sh use a fake sysfs tree. They cover an external display's backlight winning over the Apple and DDC paths, the OSD, 1% steps, a laptop screen with a GPU backlight on its connector still using omarchy-hw-display, a Studio Display without a kernel backlight still using asdcontrol, and a disconnected same-name connector on another card being skipped.
  • ./test/all, bin/omarchy commands --check and the bin/ syntax check pass, apart from seven shell tests (agent-usage-update, arm-channel-staging, clipboard, monitor-output-name, monitor-scaling, package-build-contract, settings-package-units), which fail the same way without this PR's changes.
  • On an Apple Silicon laptop with a Studio Display on DP-2: with the Studio Display focused, the brightness keys step it with the OSD and no sudo prompt, and ALT gives 1% steps. With the laptop screen focused, the keys change the panel. SHIFT still controls the keyboard backlight.

Hyprland monitor names are DRM connector names, so a backlight the kernel
registers on the focused monitor's connector is used through the existing
brightnessctl path before the Apple asdcontrol and DDC fallbacks. This lets
the Studio Display use the plain brightness keys and OSD on kernels that
expose its DCP backlight, without a sudo prompt holding the key lock.

Signed-off-by: Wes Grimes <wesgrimes@hey.com>
GPU drivers such as i915 register the panel backlight on the eDP
connector, which may not be the one driving the panel (gmux on dual-GPU
Macs). Only external connectors take the connector backlight, so
internal panels keep omarchy-hw-display's pick.

Signed-off-by: Wes Grimes <wesgrimes@hey.com>
@wesleygrimes wesleygrimes changed the title Drive the focused display's connector backlight from the brightness keys Make brightness keys work on external displays with a kernel backlight Oct 3, 2026
@scottjones

scottjones commented Oct 4, 2026 •

Copy link
Copy Markdown
Collaborator

Thanks Wes, this is a good fix. omarchy-mac is winding down, though, after the split: the desktop, brightness keys included, now lives in omacom/omarchy, and the external-backlight check isn't Mac-specific anyway, so it belongs upstream (CONTRIBUTING).

Could you open it against omacom/omarchy's quattro? Its omarchy-brightness-display is identical to your base here, and your diff applies cleanly, so it should be a straight re-open. It touches the same file as omacom#13362 (Marcelo's convergence PR), so whichever lands second will need a small rebase.

Separately, the sudo prompt holding the brightness lock until it times out deserves its own fix. It still bites Studio Display owners on kernels without iconidentify/aurora-linux#15, and it drops brightness key presses for the laptop screen too.

@wesleygrimes

Copy link
Copy Markdown
Collaborator Author

Thanks Scott, reopened upstream as omacom#14323 against quattro. I'll do the sudo lock fix as a separate PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants